\section{Related Work}
\label{sec:related}
There are vast literatures on TCP congestion control. However, our idea that ATCP 
combines rate control, flow scheduling and cloud adaptiveness is more or less
different from existing works.

MulTCP~\cite{multcp} and AIMD(a,b) TCP~\cite{aimdab} all proposes that by changing additive increase rate
the TCP flow's throughput and loss ratio changes. But they only study single flow's
throughput, and observe multiple flows' performance by simulation.
In ATCP, we provide a theoretical proof about the precise bandwidth allocation
when flows contending.

Rai et al. propose size-based flow scheduling algorithms like Shortest Job First(SJF)
, Shortest Remaining Processing Time (SRPT) and Least Attained Service (LAS) in~\cite{size-based},
They use simulation to show that these scheduling algorithms reduce job completion time.
But they do not mention how to control flow rate and their solution is not flow agnostic.

Gorinsky et al. provide the theoretical proof~\cite{fair} that their
Shortest Fair Sojourn (SFS), Optimistic Fair Sojourn Protocol (OFSP) 
and Shortest Fair Sojourn (SFS) scheduling policies
are fair without starving any flows. We use their proof techniques to proof our small flow preferred scheduling
lead to smaller average completion time.

DCTCP\cite{dctcp} uses ECN to notify the end-host of congestion in the
network, which the end-host then uses to modulate its congestion window.
DCTCP also reduces the completion time by reducing router's queue length.
However, it does not explicitly help short flows like our
approach does.

In $D^3$\cite{D3}, 
the endhosts encode deadline requirements within packet headers
using which the intermediate router computes flows' bandwidth.
The scheduling algorithm tries to satisfy as many flows' deadlines as
possible. However, this approach changes router hardware as well 
as applications.
ATCP only makes small changes to endhosts. The trade-off is that ATCP
cannot provide explicit deadline guarantees; but as our results show,
it can improve the performance a significant fraction of short flows
compared to status quo.

D2TCP~\cite{d2tcp} uses both ECN flag and deadline knowledge to adjust the congestion window,
so that D2TCP can solve both bursty fan-in problem and assign larger bandwidth to 
the flows near deadlines. However, D2TCP still takes applications' deadlines as input
to compute congestion window changes, which is not flow agnostic.

Seawall\cite{seawall} uses weighted TCP to control sending rate, but
the authors introduce a different granularity for flow control (VMs, or entity).
Seawall requires tremendous changes to host software.
Also, it is non-trivial to modify applications to provide weights. 
We note that ATCP can be complimentary to Seawall. It can
be viewed as a way to do dynamic bandwidth allocation among flows
corresponding to the same network entity.

QoS is another way to allocate bandwidth to flows; it maintains 
priority queues in the switches. However, typical
approaches need operator involvement and configuration for each flow.
And there are not sufficient amount of queues for various applications. 
